`ChannelManager::force_close_channel_with_peer` takes the peer's
node_id as a parameter and then returns it, presumably leftover
from before we stored channels indexed by peers.

Here we simply drop the return value.

When a channel is "coop" closed prior to it being funded, it is
closed immediately. Instead of reporting
`ClosureReason::*InitiatedCooperativeClosure` (which would be
somewhat misleading), we report
`ClosureReason::CounterpartyCoopClosedUnfundedCHannel` when our
counterparty does it. However, when we do it, we report
`ClosureReason::HolderForceClosed`, which is highly confusing given
the user did *not* call a force-closure method.

Instead, here, we add a
`ClosureReason::LocallyCoopClosedUnfundedChannel` to match the
`CounterpartyCoopClosedUnfundedCHannel` variant and use it.

`ClosureReason::HolderForceClosed` says explicitly in its docs
"Closure generated from `ChannelManager...`, called by the user."
However, we were using it extensively when we fail a channel due to
errors handling messages or generating our own responses.

Here, we convert these cases to the catch-all
`ClosureReason::ProcessingError` which exists to communicate errors
including a string that describes what happened.

This should substantially improve debug-ability in closure cases
by avoiding having to pull up logs.

Here we fix a few cases of swallowing appropriate `ClosureReason`s
and expand `ClosureReason::FundingTimedOut` to include when we
didn't get a channel funded in time, rather than using
`HolderForceClosed`.

In d17e759 we added the ability
for users to decide which message to send to peers when we
force-close a channel. Here we pipe that message back out through
the channel closure event via a new `message` field in
`ClosureReason::HolderForceClosed`.

This is nice to have but more importantly will be used in a coming
commit to simplify the internal interface to the force-closure
logic.

Removes totally unnecessary `#[inline]`s  on `MsgHandleErrInternal`
methods (LLVM will decide for us if it makes sense to inline
something, explicit `#[inline(always)]` belongs only on incredibly
performance-sensitive code and `#[inline]` belongs only on short
public methods that should be inlined into downstream crates) and
`rustfmt` `MsgHandleErrInternal::from_chan_no_close`.

`ChannelManager` has two public methods to force-close a (single)
channel - `force_close_broadcasting_latest_txn` and
`force_close_without_broadcasting_txn`. The second exists to allow
a user who has restored a stale backup to (sort of) recover their
funds by starting, force-closing channels without broadcasting
their latest state, and only then reconnecting to peers (which
would otherwise cause a panic due to the stale state).

To my knowledge, no one has ever implemented this (fairly
half-assed) recovery flow, and more importantly its rather
substantially broken. `ChannelMonitor` has never tracked any
concept of whether a channel is stale, and if we connect blocks
towards an HTLC time-out it will immediately broadcast the stale
state anyway.

Finally, we really shouldn't encourage users to try to "recover"
from a stale state by running an otherwise-operational node on the
other end. Rather, we should formalize such a recovery flow by
having a `ChainMonitor` variant that takes a list of
`ChannelMonitor`s and claims available funds, dropping the
`ChannelManager` entirely.

While work continues towards that goal, having long-broken
functionality in `ChannelManager` is also not acceptable, so here
we simply remove the "without broadcasting" force-closure version.

Fixes lightningdevkit#2875

While most of our closure logic mostly lives in
`locked_close_chan`, some important steps happen in
`convert_channel_err` and `handle_error` (mostly broadcasting a
channel closure `ChannelUpdate` and sending a relevant error
message to our peer).

While its fine to use `locked_close_chan` directly when we
manually write out the relevant extra steps, its nice to avoid it
to DRY up some of our closure logic, which we do here.

`Channel`'s new `FundingScope` exists to store both the channel's
live funding information as well as any in-flight splices. In order
to keep the patches which introduced and began using it simple, it
was exposed outside of `channel.rs` to `channelmanager.rs`,
breaking the `Channel` abstraction somewhat.

Here we remove one case of `FundingScope` being passed around
`channelmanager.rs` (in the hopes of eventually keeping it entirely
contained within `channel.rs`). Specifically, we remove the
`FundingScope` parameter from `locked_close_channel`.

In a previous commit, we removed the ability for users to pick
whether we will broadcast a commitment transaction on channel
closure. However, that doesn't mean that there is no value in never
broadcasting commitment transactions on channel closure. Rather, we
use it to avoid broadcasting transactions which we know cannot
confirm if the channel's funding transaction was not broadcasted.

Here we make this relationship more formal by splitting the
force-closure handling logic in `Channel` into the existing
`ChannelContext::force_shutdown` as well as a new
`ChannelContext::abandon_unfunded_chan`.
`ChannelContext::force_shutdown` is the only public method, but it
delegates to `abandon_unfunded_chan` based on the channel's state.

This has the nice side effect of avoiding commitment transaction
broadcasting when a batch open fails to get past the funding stage.